 |
Customers
WIRELESS ACCESS AND FMC SOLUTIONS
WIRELINE SOLUTIONS
CABLE SOLUTIONS
INTERCONNECT AND PEERING SOLUTIONS
ENTERPRISE AND CONTACT CENTER SOLUTIONS
Government solutions
IMS & SBCs
|
|
Contact centers are in the middle of a long-term transition from traditional TDM-based telephony to Voice over IP (VoIP). VoIP delivers significantly lower recurring costs and is a key enabler of contact center virtualization, allowing agents to work anywhere they have IP network access, including at home and while mobile. VoIP is also the critical first step toward truly comprehensive IP-based interactive communications - presence-enabled audio and videoconferencing, chat/instant messaging (IM), multimedia collaboration and communications-enabled business applications. Many contact centers are adding these services as integrated suites of applications referred to as Unified Communications (UC).
VoIP and UC are widely expected to help agents collaborate more effectively with other agents and non-contact center coworkers, thereby increasing first call resolution rates and decreasing average call resolution times. Voice and other real-time communication services over IP will help contact centers improve customer sat-isfaction and reduce overall operating and capital costs. But significant challenges in security, interoperability, service assurance and regulatory compliance emerge as contact centers begin migrating voice, conferencing and other real-time interactive services from TDM to IP networks.
Session border controllers (SBCs), product solutions extensively used by service providers to address these shortcomings, are being deployed by contact centers to enable the delivery of secure, high-quality, real-time interactive communications, including VoIP and UC. Similarly, service providers are using SBCs in their new offerings for their hosted and outsourced contact center solutions.
Acme Packet session border control solutions for IP contact centers
Acme Packet® session border controllers (SBCs) enable contact centers to assert these controls over their four critical IP network borders, as shown in Figure 1:
- IP trunking border—connections over SIP or H.323 trunks to service provider IP networks, affording connectivity to PSTN end-points via media gateways in the service provider’s IP network
- Private managed IP network border—peering connections to IP network service providers whose business and consumer customers originate calls from native IP phones and VoIP or UC soft clients on PCs and handhelds; no media conversions between TDM and IP occur anywhere in the session
- Internet border—connections to the public Internet over which home-based agents, mobile employees, and small remote agent pools establish VPN connections into the contact center, and over which customers establish unsecured VoIP calls and other IP interactive communications to the contact center using public-Internet VoIP services like Skype or Vonage
- Virtual contact center border—connections over private IP network services (such as MPLS) to distributed pools of contact center agents, contact center outsourcing service providers and contact center hosting providers.
Figure 1: The four critical IP network borders of the CONTACT center
The first critical IP network border over which the contact center must assert control is the IP trunking border that connects it over IP trunking services (SIP or H.323 trunks) to service provider IP networks, which in turn connect to the PSTN via service provider media gateways. Using IP trunks instead of ISDN-PRIs offers contact centers a number of cost-saving and operational advantages (see sidebar).
Benefits of IP trunking
Replacing ISDN-PRI, T1/E1 or larger TDM trunks with one or more IP trunks allows the contact center to:
- Reduce PSTN call termination costs by letting IP trunks route each outbound call over the service provider IP backbone to the service provider media gateway in closest proximity to the call’s destination
- Reduce capital and operating costs by eliminating media gateways and TDM trunks in the contact center and supporting voice applications on the existing data network
- Add network fault tolerance (also referred to as geo-redundancy) by provisioning multiple IP trunks to diverse PoPs and/or diverse service providers
- Simplify operations by relegating media gateway and PSTN interconnection management to the service provider
- Cut the time to provision and deploy IP interconnects to a matter of days, as opposed to the months typically needed to provision and deploy TDM services
|
Despite these benefits, IP trunks present some challenges. First, the service provider’s IP network, like any IP network, cannot be trusted. It provides an attack vector for signaling and media overloads, DoS and DDoS attacks, and viruses and worms. These security threats can cripple contact center ACDs and IP PBXs, sap network performance and call quality and compromise the confidentiality of voice traffic.
Next, the IP trunking service may use signaling, networking pro-tocols, encryption methods and codecs that are incompatible with contact center VoIP infrastructure. These incompatibilities must be mediated.
On the plus side, the IP trunking border provides a logical place to add session routing intelligence, improving the contact center’s ability to recover from network failures, to choose the most optimal service providers and routes for outbound sessions (based on characteristics like cost, time of day, codec type, caller location and network congestion) and to generate reports necessary for traffic management and planning.
Most contact centers must record some or all of their calls for regulatory, quality management and/or training purposes. The IP trunking border provides an optimal point at which to replicate ireal-time communications sessions for delivery to a call recording system.
To effectively take advantage of IP trunking services, contact centers must deploy SBCs to perform the following functions:
Security
The contact center is vulnerable at the IP trunking border to attacks by service provider employees motivated by malice or profit, and to non-malicious signaling overloads caused by events like power outages. These attacks and overloads can cause outages in contact center voice and other interactive IP communication services. The SBC must defend contact center signaling elements (as well as itself) against these DoS/DDoS attacks and overloads.
To prevent attacks from external IP networks, the SBC must enforce access control policies by limiting incoming sessions to the IP addresses of service provider peer SBCs. Knowledge of contact center IP addressing schemes and topologies can be used to compromise user privacy and mount directed attacks on contact center resources. Network Address Translation (NAT) must be employed to hide the topology of IP interactive communications servers and internal endpoints defending against directed attacks and protecting user privacy.
Intrusion monitoring and reporting should be provided by the SBC to help the contact center validate that its service providers are complying with security SLAs. Fraudulent use of contact center resources, e.g., unauthorized use of international calling or telepresence services by employees, can be costly and can adversely affect legitimate usage; the SBC should be able to detect and report on such unauthorized usage.
Application reach maximization
Incompatibilities between contact center signaling elements and service provider infrastructure for IP trunks must be mediated. The SBC must provide signaling protocol interworking for SIP trunks to H.323 IP PBXs, H.323 trunks to H.323 or SIP IP PBXs and between differing vendor implementations of SIP. Other required types of interworking that the SBC may need to provide include: transport protocol interworking for TCP, UDP and SCTP; encryption protocol interworking for TLS, MTLS, SRTP, and IPsec; and response code translations. The SBC may also need to provide IP address translation between overlapping private IP address spaces or between IPv4 and IPv6 addresses
SLA assurance
Given the business-critical nature of real-time communications in the contact center, the SBC must offer mechanisms to rein-force their uptime and performance. To enable contact center geo-redundancy, the SBC must be able to load-balance traffic across multiple IP trunks, monitor the health of trunks for overload and outage conditions and adjust load-balancing if a trunk reaches capacity or suffers an outage. Routing decisions should also be able to factor in quality metrics collected over time, giving preference to service providers with the best historical call quality or ASR.
When SIP trunks approach session capacity, allowing additional sessions on the same trunk degrades the quality of all sessions on the trunk. Likewise, too high a call acceptance rate can overload signaling elements. To ensure high session quality and prevent signaling element failures, the SBC must assert call admission control, refusing calls where necessary to prevent trunk saturation and signaling overload conditions.
Most contact centers utilize some combination of packet tagging and VLANs to ensure appropriate bandwidth and acceptable latency for real-time traffic at the expense of non-real-time data traffic. The SBC should support QoS marking and VLAN mapping for incoming traffic to comply with these policy mechanisms. It should also monitor and report on QoS and ASR to help the contact center validate service provider SLA compliance.
Cost optimization
The SBC must help contact center reduce service provider charges for VoIP and UC traffic via flexible session routing policies based on a variety of metrics, including least-cost routing, observed call quality and codec types. For example, the SBC might route outbound calls from the contact center to different service provider trunks depending on which offered the lowest charges based on time-of-day or caller location. Where possible, it should handle toll-free call transfers within the contact center network to reduce feature charges associated with service provider takeback-and-transfer services. The SBC should also provide flexible usage reporting for cost accounting and traffic planning purposes.
Traditional IP call recording topologies perform session replication with port mirroring in a Layer 2 switch. This approach does not offer optimum reliability and consumes an additional ACD port for every session to be recorded. Performing session replication for call recording in the SBC offers two distinct advantages. One, it offers more reliable transport of replicated sessions to the call recording system than a Layer 2-based solution. Two, moving session replication to the trunk side of the ACD eliminates consumption of an extra ACD port for every recorded session; these costly ACD ports can thus be recovered for use as agent seats.
Regulatory compliance
In addition to its use for training and quality management purposes, call recording is used extensively in contact centers for compliance with regulatory mandates like the Payment Card Industry (PCI) Data Security Standard and the Health Insurance Portability and Accountability Act (HIPAA). The SBC must provide a cost-effective and reliable session replication mechanism for recording IP communications services signaling and media.
In North America, contact centers must comply with regulations for E9-1-1 services, which require that emergency calls be handled with appropriate priority. The SBC must be able to identify emergency calls from anywhere within the virtual contact center, exempt them from admission control policies and route them with priority to the appropriate Public Safety Answering Point (PSAP).
2: Private managed IP network border
This border presents a number of additional challenges. For example, besides non-malicious signaling overloads and threats from service provider insiders, the contact center is vulnerable on this border to DoS attacks and malware originating from IP endpoints in the private managed network. Signaling protocol variations and other incompatibilities between the private managed IP network and the contact center must be overcome through interworking and normalization. To protect call quality and maximize contact center availability, admission control must be asserted and health monitoring of critical signaling elements performed.
The contact center must deploy SBCs on the private managed IP network border to perform the following functions:
Security
The contact center is vulnerable at this border to a range of attacks originating from native-IP end-users and from service provider insiders. While less threat-prone than the public Internet border, the private managed IP network border carries significantly higher security risks than the IP trunking border (Border 1). For example, malicious DoS/DDoS attacks and non-malicious signaling overloads (e.g., mass calling events) can traverse this border to bring down contact center signaling resources.
The SBC must therefore police inbound sessions at this border to avert both non-malicious overload events and malicious attacks; it must defend itself from attacks and overloads, otherwise a successful DoS attack on the SBC would leave contact center infrastructure open to subsequent attacks.
The SBC must employ NAT to hide the topology and IP addresses of signaling and media elements, thereby thwarting directed attacks. It should also provide monitoring and reporting for use in anomaly detection and post-attack forensics. On the malware front, the SBC should perform deep packet inspection (DPI) on incoming sessions to detect and eliminate viruses and worms, and use behavioral analysis to identify and block generators of SPIT.
Application reach maximization
Native managed IP voice services providers may use equipment that is incompatible with contact center infrastructure for IP communications services. The SBC must be able to obviate these differences through interworking capabilities, including the ability to mediate technology differences in signaling protocols (e.g., SIP vs. H.323), vendor implementations of signaling protocols (e.g., incompatibilities between the SIP used by contact center signaling elements and the service provider’s infrastructure, such as a cable MSO’s cable modem termination system), transport protocols (TCP, UDP and SCTP), encryption protocols (TLS, MTLS, SRTP and IPsec), and different versions of IP (IPv4 vs. IPv6).
SLA assurance
The SBC must maintain the uptime and performance of contact center IP voice and UC infrastructure via session admission control policies that intelligently assesses available bandwidth and session agent capacity. The SBC must manage incoming sessions so as not to exceed the maximum number of allowed sessions or maximum rate of session establishment that the contact center’s signaling elements can handle. It should also monitor the health of logically-adjacent elements (such as IP-PBXs, ACDs, softswitches, and SIP registrars) and reroute and redistribute traffic around those elements when they suffer overload conditions or failures.
3: Internet border
The third critical IP network border over which the contact center must assert control is the Internet border, defined by connections to the public Internet. This border provides access to the contact center by two critical communities: employees who use VPN links over the public Internet to participate as members of the virtual contact center, including agents in distributed offices, home-based agents, and mobile employees; and end-users who call the contact center via public-Internet VoIP services like Skype and Vonage.
Public Internet VPN connections are an important enabler for contact center virtualization, allowing small pools of agents based in remote offices as well as home-based agents and mobile employees to cost-effectively connect to the contact center. But com-pared to other contact center IP network borders, the Internet border presents the broadest array of security threats, including malicious DoS/DDoS attacks on session control elements, non-malicious signaling overload events, viruses and worms specifically created to exploit real-time communications and SPIT.
Extending the reach of IP interactive communications from the contact center to remote agents through this border is also problematic due to the firewall/NAT traversal problem. Reaching home-based agents and small contact center pools over public Internet connections demands a scalable, manageable NAT traversal solution that does not require remote users to reconfigure their Internet access devices.
Depending upon industry and employee role, the privacy of sessions established across this border may be necessary for business reasons or compulsory for regulatory compliance, especially given the perceived higher risk of eavesdropping on the public Internet. However, homogeneous end-to-end encryption is not always feasible, as not all IP phones, media gateways or voice mail servers have the requisite encryption capabilities.
Finally, session quality across public Internet links can vary significantly, and must be monitored regularly to determine whether upgrading a pool of agents from an Internet connection to a higher-quality private network connection such as MPLS would be appropriate.
To address these challenges, the contact center requires SBCs on the Internet border to perform the following functions:
Security
The SBC must protect contact center signaling and media elements and itself from the broad range of attacks that originate on Internet-connected endpoints, including malicious DoS/DDoS attacks and non-malicious signaling overload events. It should perform deep packet inspection on incoming sessions to detect and eliminate viruses and worms, and use behavioral analysis to identify and block generators of SPIT.
The SBC should hide the topology and IP addresses of signaling and media elements to thwart directed attacks from across the Internet border. It should also monitor the Internet border for anomalous traffic and generate reports for use in post-attack foren-sics. Where appropriate due to the high value or sensitive nature of the content, the SBC should support encryption of signaling and media to protect the confidentiality of remote agent sessions and customer calls.
Application reach maximization
The SBC must provide hosted NAT traversal so that IP interactive communications sessions can be established to home-based agents without the remote employee having to install new CPE or reconfigure their existing firewall/NAT gateways. In sessions where each endpoint uses a different codec or frame rate, the SBC should provide transcoding or transrating.
SLA assurance
The SBC must perform a variety of functions to provide high-performance, highly available access to Internet-connected agents and consumer callers without exposing contact center signaling elements to DoS attacks and signaling overloads. Session admission control should be asserted to defend against DoS/DDoS attacks and avert call quality problems due to trunk saturation. To improve session quality for real-time communications between remote endpoints, the SBC should selectively release the media portion of a session so that endpoints can communicate directly, peer-to-peer, without hairpinning the media stream through the SBC.
The SBC must also provide quality of experience (QoE) reporting to help planners understand when an Internet connection to a remote agent pool needs to be upgraded to a higher-quality private WAN connection such as MPLS.
Regulatory compliance
For distributed agent pools and home-based agents, the SBC must enable compliance with government and industry regula-tions, including E9-1-1 handling to ensure that any emergency call placed by a remote agent is given the necessary priority.
Where needed for compliance with government or commercial privacy regulations, the SBC must support encryption of signaling and media to protect the confidentiality of remote agent sessions and customer calls. It should also offer encryption interworking to enable encryption end-to-end (using different encryption protocols on either side of the SBC) or partial encryption (so that the session can at least be encrypted between the SBC and the endpoint that supports encryption).
4: Virtual contact center border
The fourth IP network border over which the contact center must assert control is the virtual contact center border, encompassing private IP network connections to remote pools of contact center agents. These sites may consist of large contact centers established for business continuity purposes, regional offices, international offices, and agents working for contact center outsourcing service providers. These locations are large enough to require the bandwidth and reliability offered by private IP network services like MPLS. These services are also generally mandated for connecting the contact center to outsourcing or hosting service providers.
Because security is so critical to the business of enterprise-oriented private IP network service providers, outsourcers and hosters, the security risk associated with this border is low compared to Borders 2 and 3. Nonetheless, protecting the perfor-mance and availability of virtual contact center resources connected across this border is critical.
To overcome these challenges, contact centers need to deploy SBCs on the virtual contact center border to perform the following functions:
Security
The SBC must perform a number of functions to defend contact center IP interactive communications signaling elements (as well as itself) against DoS and DDoS attacks and signaling overloads originating inside the service provider, outsourcing provider or hosting provider network. The primary threat here is a service provider employee, an insider motivated by malice or financial gain.
The SBC should enforce access control policies by limiting incoming sessions to the IP addresses of service provider peer SBCs. Network Address Translation (NAT) must be employed to hide the topology of contact center signaling elements and internal endpoints, thereby foiling directed attacks and protecting user privacy. The SBC must provide intrusion monitoring and reporting capabilities to validate service provider compliance on security and network performance SLAs.
Application reach maximization
The SBC should provide interworking capabilities to mediate technology differences between signaling and media infrastructure elements across this border, including signaling protocols (e.g., SIP vs. H.323), variations in vendor implementations of signaling protocols, transport protocols (TCP, UDP and SCTP), and encryption protocols (TLS, MTLS, SRTP and IPsec). The SBC may also need to provide IP address translation between overlapping private IP address spaces or between IPv4 and IPv6 addresses.
SLA assurance
The SBC has a crucial role to play in maintaining service levels in the virtual contact center. The SBC must intelligently load-balance traffic among redundant contact center infrastructure elements, e.g., IP-PBX clusters. It should be able to monitor the health and traffic load on critical IP communications infrastructure elements, including ACDs, IP-PBXs, media gateways, softswitches, and SIP proxies. When it detects a problem—a hardware failure or the exceeding a capacity threshold—it should adjust accordingly, shifting traffic to one or more redundant standby or load-sharing systems. This same intelligent load balancing can help the contact center handle peak-period calling volumes by routing sessions to a contact center outsourcer for overflow call handling. Where appropriate, the SBC should also assert session admission control to prevent trunk saturation and signaling element overload.
The SBC must also work with traffic prioritization and QoS mechanisms to ensure that real-time communications traffic receives the bandwidth and low latency it requires at the expense of non-real-time data. Thus, it must provide transport control for incoming sessions with QoS marking and VLAN mapping, and monitoring capabilities like QoS and ASR reporting to validate service provider SLA compliance. This function may require the SBC to provide interworking between different types of VLANs.
|
|
